This disclosure relates to debugging peripheral circuits, such as processors, on an integrated circuit chip. The disclosure is particularly relevant to debugging peripheral circuits which form part of a System-on-Chip (SoC).
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
Thus, the development of SoC devices required associated development in debugging technology, which lead to the integration of some debug functionality onto the SoC. It is now customary for each core device to have an associated debug unit. Typically, the debug unit can observe the core device, for example by collecting trace data from that core device. The collected debug data is assembled into debug messages and routed through the integrated circuit chip, typically to be funnelled off chip via a debug port to an external debug controller.
The debug controller selects the type of trace data that is to be collected by setting the configuration of the debug unit. For example, that configuration may specify parameters of internal filters of the debug unit; the debug unit only collecting and outputting trace data when the parameters of those filters are met. In order to accurately process a portion of trace data, the debug controller needs to know which configuration the debug unit had at the time the portion of trace data was collected. When the debug controller instructs the debug unit to change configuration, there is a period of time during which the debug controller receives trace data but does not know which configuration the debug unit had at the time that trace data was collected. To solve this problem, the debug controller may instruct the debug unit to stop tracing prior to instructing the debug unit to change configuration, and then instruct the debug unit to start tracing again after the debug unit has changed configuration. However, this solution results in a period of time during which trace data is not collected, and hence a period of time during which the debug controller is unable to analyse the core device.